Skip to content

DX9 Backend: Recreate destroyed textures on CreateDeviceObjects()#8811

Closed
Intemporel wants to merge 1 commit into
ocornut:dockingfrom
Intemporel:dx9_recreate_textures_during_create_device_objects
Closed

DX9 Backend: Recreate destroyed textures on CreateDeviceObjects()#8811
Intemporel wants to merge 1 commit into
ocornut:dockingfrom
Intemporel:dx9_recreate_textures_during_create_device_objects

Conversation

@Intemporel
Copy link
Copy Markdown

@Intemporel Intemporel commented Jul 16, 2025 •
edited
Loading

Fix an issue where the textures where never re-created after invalidating the device objects, usually happen during:

ImGui_ImplDX9_InvalidateDeviceObjects();
device->Reset(&d3dpp);
ImGui_ImplDX9_CreateDeviceObjects();

This was previously crashing for the next ImGui::Begin(), during the PushTexture for the ContainerAtlas ( in my case ):

// Setup draw list and outer clipping rectangle
IM_ASSERT(window->DrawList->CmdBuffer.Size == 1 && window->DrawList->CmdBuffer[0].ElemCount == 0);
window->DrawList->PushTexture(g.Font->ContainerAtlas->TexRef);
PushClipRect(host_rect.Min, host_rect.Max, false);

@Intemporel Intemporel changed the title Update imgui_impl_dx9.cpp DX9 Backend: Recreate destroyed textures on CreateDeviceObjects() Jul 17, 2025
@ocornut
Copy link
Copy Markdown
Owner

ocornut commented Jul 21, 2025

The code was designed to support this. When the backend destroys a texture we automatically set it back to _WantCreate for a next iteration.

I however notice that it currently doesn't work if you call ImGui_ImplDX9_InvalidateDeviceObjects() from inside the ImGui Frame Scope, so I am going to try fixing it.

If you move the reset before ImGui::NewFrame() it should work.

@ocornut ocornut added this to the v1.93 milestone Aug 11, 2025
@ocornut ocornut mentioned this pull request Oct 1, 2025
Closed
@ocornut ocornut added the bug label Oct 1, 2025
ocornut added a commit that referenced this pull request Oct 1, 2025
@ocornut
Textures: fixed a crash if a texture marked as _WantDestroy by a back…
ea564a6 
…end after it had already been destroyed. (#8977, #8811)
@ocornut
Copy link
Copy Markdown
Owner

ocornut commented Oct 1, 2025

I believe the right fix would be to change ImTextureData::SetStatus()

    void SetStatus(ImTextureStatus status)
    {
        if (status == ImTextureStatus_Destroyed && !WantDestroyNextFrame)
            Status = ImTextureStatus_WantCreate;
        else
            Status = status;
    }

Basically if core doesn't request the destroy we always get back in WantCreate stat.e

ocornut added a commit that referenced this pull request Oct 1, 2025
@ocornut
Textures: allowed backend to destroy texture while inside the NewFram…
8c22b8a 
…e/EndFrame scope. (#8811)
@ocornut
Copy link
Copy Markdown
Owner

ocornut commented Oct 1, 2025

This should now be fixed by 8c22b8a.
Thanks for reporting and sorry for my late solution for this!

@ocornut ocornut closed this Oct 1, 2025
ocornut pushed a commit that referenced this pull request Jan 3, 2026
@sammyfreg
Textures: prevent assert/crash of having a destroyed texture recreate…
25158fe 
…d without the pixels data available (#9150, #8811)

Amend 8c22b8a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

backends bug

Projects

None yet

Milestone

v1.93

Development

Successfully merging this pull request may close these issues.

2 participants

@Intemporel @ocornut